A CORS demisztifikálása: Mélyreható betekintés a JavaScript előzetes kérések (preflight request) kezelésébe

A webfejlesztés folyamatosan bővülő világában a biztonság elsődleges fontosságú. A Cross-Origin Resource Sharing (CORS) egy kulcsfontosságú biztonsági mechanizmus, amelyet a webböngészők alkalmaznak annak érdekében, hogy a weboldalak ne tudjanak kéréseket intézni egy másik domainhez, mint amelyikről az oldalt betöltötték. Ez egy alapvető biztonsági funkció, amelynek célja, hogy megakadályozza a rosszindulatú webhelyeket abban, hogy hozzáférjenek érzékeny adatokhoz. Ez az átfogó útmutató a CORS bonyolultságát tárgyalja, különös tekintettel az előzetes kérések (preflight request) kezelésére. Felfedezzük a CORS „miértjét”, „mitjét” és „hogyanját”, gyakorlati példákkal és megoldásokkal a fejlesztők által világszerte tapasztalt gyakori problémákra.

Az Azonos Eredetű Szabályzat (Same-Origin Policy) megértése

A CORS középpontjában az Azonos Eredetű Szabályzat (Same-Origin Policy - SOP) áll. Ez a szabályzat egy böngésző szintű biztonsági mechanizmus, amely korlátozza az egyik eredetről futó szkripteket abban, hogy egy másik eredetről származó erőforrásokhoz férjenek hozzá. Egy eredetet a protokoll (pl. HTTP vagy HTTPS), a domain (pl. example.com) és a port (pl. 80 vagy 443) határoz meg. Két URL akkor azonos eredetű, ha ez a három komponens pontosan megegyezik.

Például:

• A https://www.example.com/app1/index.html és a https://www.example.com/app2/index.html azonos eredetűek (azonos protokoll, domain és port).
• A https://www.example.com/index.html és a http://www.example.com/index.html eltérő eredetűek (eltérő protokollok).
• A https://www.example.com/index.html és a https://api.example.com/index.html eltérő eredetűek (az aldomainek eltérő domainnek számítanak).
• A https://www.example.com:8080/index.html és a https://www.example.com/index.html eltérő eredetűek (eltérő portok).

Az SOP célja, hogy megakadályozza a rosszindulatú szkripteket az egyik webhelyen abban, hogy hozzáférjenek érzékeny adatokhoz, például sütikhez vagy felhasználói hitelesítési információkhoz egy másik webhelyen. Bár a biztonság szempontjából elengedhetetlen, az SOP korlátozó is lehet, különösen, ha legitim, eltérő eredetű kérésekre van szükség.

Mi az a Cross-Origin Resource Sharing (CORS)?

A CORS egy olyan mechanizmus, amely lehetővé teszi a szerverek számára, hogy meghatározzák, mely eredetek (domainek, sémák vagy portok) jogosultak hozzáférni az erőforrásaikhoz. Lényegében fellazítja az SOP-t, lehetővé téve az ellenőrzött, eltérő eredetű hozzáférést. A CORS HTTP fejlécek segítségével valósul meg, amelyeket az ügyfél (jellemzően egy webböngésző) és a szerver között cserélnek.

Amikor egy böngésző eltérő eredetű kérést indít (azaz egy másik eredethez intéz kérést, mint az aktuális oldal), először ellenőrzi, hogy a szerver engedélyezi-e a kérést. Ezt a szerver válaszában található Access-Control-Allow-Origin fejléc vizsgálatával teszi. Ha a kérés eredete szerepel ebben a fejlécben (vagy ha a fejléc értéke *, ami minden eredetet engedélyez), a böngésző engedélyezi a kérés folytatását. Ellenkező esetben a böngésző blokkolja a kérést, megakadályozva, hogy a JavaScript kód hozzáférjen a válasz adataihoz.

Az előzetes kérések (Preflight Request) szerepe

Bizonyos típusú, eltérő eredetű kérések esetében a böngésző egy előzetes kérést (preflight request) kezdeményez. Ez egy OPTIONS kérés, amelyet a tényleges kérés előtt küld a szervernek. Az előzetes kérés célja annak megállapítása, hogy a szerver hajlandó-e elfogadni a tényleges kérést. A szerver az előzetes kérésre az engedélyezett metódusokról, fejlécekről és egyéb korlátozásokról szóló információkkal válaszol.

Az előzetes kérések akkor aktiválódnak, ha az eltérő eredetű kérés az alábbi feltételek bármelyikének megfelel:

• A kérés metódusa nem GET, HEAD vagy POST.
• A kérés egyéni fejléceket tartalmaz (azaz olyan fejléceket, amelyeket nem a böngésző ad hozzá automatikusan).
• A Content-Type fejléc értéke nem application/x-www-form-urlencoded, multipart/form-data vagy text/plain.
• A kérés ReadableStream objektumokat használ a törzsben.

Például egy PUT kérés application/json Content-Type-pal előzetes kérést fog kiváltani, mivel az engedélyezettektől eltérő metódust és egy potenciálisan nem engedélyezett tartalomtípust használ.

Miért van szükség az előzetes kérésekre?

Az előzetes kérések elengedhetetlenek a biztonság szempontjából, mert lehetőséget adnak a szervernek, hogy elutasítsa a potenciálisan káros, eltérő eredetű kéréseket, mielőtt azok végrehajtódnának. Előzetes kérések nélkül egy rosszindulatú webhely potenciálisan tetszőleges kéréseket küldhetne egy szervernek annak kifejezett hozzájárulása nélkül. Az előzetes kérés lehetővé teszi a szerver számára, hogy ellenőrizze a kérés elfogadhatóságát, és megakadályozza a potenciálisan káros műveleteket.

Az előzetes kérések kezelése szerveroldalon

Az előzetes kérések megfelelő kezelése kulcsfontosságú a webalkalmazás helyes és biztonságos működéséhez. A szervernek a megfelelő CORS fejlécekkel kell válaszolnia az OPTIONS kérésre, jelezve, hogy a tényleges kérés engedélyezett-e.

Itt található a legfontosabb CORS fejlécek listája, amelyeket az előzetes válaszokban használnak:

• Access-Control-Allow-Origin: Ez a fejléc határozza meg, hogy mely eredet(ek) férhetnek hozzá az erőforráshoz. Beállítható egy konkrét eredetre (pl. https://www.example.com) vagy *-ra, hogy minden eredetet engedélyezzen. Azonban a * használata általában nem javasolt biztonsági okokból, különösen, ha a szerver érzékeny adatokat kezel.
• Access-Control-Allow-Methods: Ez a fejléc határozza meg, hogy mely HTTP metódusok engedélyezettek az eltérő eredetű kéréshez (pl. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Ez a fejléc határozza meg a nem szabványos HTTP fejlécek listáját, amelyek engedélyezettek a tényleges kérésben. Erre akkor van szükség, ha az ügyfél egyéni fejléceket küld, mint például X-Custom-Header vagy Authorization.
• Access-Control-Allow-Credentials: Ez a fejléc jelzi, hogy a tényleges kérés tartalmazhat-e hitelesítő adatokat, például sütiket vagy engedélyezési fejléceket. Értékét true-ra kell állítani, ha az ügyféloldali kód hitelesítő adatokat küld, és a szervernek el kell fogadnia azokat. Megjegyzés: ha ez a fejléc true-ra van állítva, az Access-Control-Allow-Origin *nem* lehet *. Meg kell adni a konkrét eredetet.
• Access-Control-Max-Age: Ez a fejléc határozza meg azt a maximális időtartamot (másodpercekben), ameddig a böngésző gyorsítótárazhatja az előzetes választ. Ez segíthet a teljesítmény javításában azáltal, hogy csökkenti a küldött előzetes kérések számát.

Példa: Az előzetes kérések kezelése Node.js-ben Express segítségével

Íme egy példa arra, hogyan kezelhetők az előzetes kérések egy Node.js alkalmazásban az Express keretrendszer használatával:

const express = require('express');
const cors = require('cors');
const app = express();

// CORS engedélyezése minden eredet számára (csak fejlesztési célokra!)
// Éles környezetben adjon meg engedélyezett eredeteket a nagyobb biztonság érdekében.
app.use(cors()); //vagy app.use(cors({origin: 'https://www.example.com'}));

// Útvonal az OPTIONS kérések (előzetes kérés) kezelésére
app.options('/data', cors()); // CORS engedélyezése egyetlen útvonalra. Vagy adjon meg eredetet: cors({origin: 'https://www.example.com'})

// Útvonal a GET kérések kezelésére
app.get('/data', (req, res) => {
  res.json({ message: 'Ez egy eltérő eredetű adat!' });
});


// Útvonal egy előzetes kérés és egy post kérés kezelésére
app.options('/resource', cors()); // előzetes kérés (pre-flight) engedélyezése a DELETE kéréshez
app.delete('/resource', cors(), (req, res, next) => {
  res.send('erőforrás törlése')
})


const port = 3000;
app.listen(port, () => {
  console.log(`A szerver a ${port} porton fut`);
});

Ebben a példában a cors middleware-t használjuk a CORS kérések kezelésére. A részletesebb szabályozás érdekében a CORS útvonalanként is engedélyezhető. Megjegyzés: éles környezetben erősen ajánlott megadni az engedélyezett eredeteket az origin opcióval ahelyett, hogy minden eredetet engedélyeznénk. Minden eredet engedélyezése a * használatával biztonsági réseket tárhat fel az alkalmazásban.

Példa: Az előzetes kérések kezelése Pythonban Flask segítségével

Íme egy példa arra, hogyan kezelhetők az előzetes kérések egy Python alkalmazásban a Flask keretrendszer és a flask_cors kiterjesztés használatával:

from flask import Flask, jsonify
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)  # CORS engedélyezése minden útvonalra

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "Ez egy eltérő eredetű adat!"}
    return jsonify(data)

if __name__ == '__main__':
    app.run(debug=True)

Ez a legegyszerűbb használat. Ahogy korábban is, az eredetek korlátozhatók. Részletekért lásd a flask-cors dokumentációját.

Példa: Az előzetes kérések kezelése Javában Spring Boot segítségével

Íme egy példa arra, hogyan kezelhetők az előzetes kérések egy Java alkalmazásban a Spring Boot használatával:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CorsApplication {

    public static void main(String[] args) {
        SpringApplication.run(CorsApplication.class, args);
    }

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/data").allowedOrigins("http://localhost:8080");
            }
        };
    }
}

És a hozzá tartozó controller:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "Ez egy eltérő eredetű adat!";
    }
}

Gyakori CORS problémák és megoldásaik

Fontossága ellenére a CORS gyakran okozhat frusztrációt a fejlesztőknek. Íme néhány gyakori CORS probléma és megoldásuk:

1. Hiba: "No 'Access-Control-Allow-Origin' header is present on the requested resource."

   Ez a hiba azt jelzi, hogy a szerver nem küldi vissza az Access-Control-Allow-Origin fejlécet a válaszában. A javításhoz győződjön meg arról, hogy a szerver úgy van konfigurálva, hogy tartalmazza ezt a fejlécet, és hogy az a megfelelő eredetre vagy *-ra van állítva (ha helyénvaló).

   Megoldás: Konfigurálja a szervert, hogy a válaszában szerepeltesse az `Access-Control-Allow-Origin` fejlécet, beállítva azt a kérelmező webhely eredetére vagy `*`-ra, hogy minden eredetet engedélyezzen (körültekintően használja).

2. Hiba: "Response to preflight request doesn't pass access control check: Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers in preflight response."

   Ez a hiba azt jelzi, hogy a szerver nem engedélyezi az egyéni fejlécet (ebben a példában az X-Custom-Header-t) az eltérő eredetű kérésben. A javításhoz győződjön meg arról, hogy a szerver az előzetes válaszában az Access-Control-Allow-Headers fejlécben szerepelteti az adott fejlécet.

   Megoldás: Adja hozzá az egyéni fejlécet (pl. `X-Custom-Header`) a szerver előzetes válaszában található `Access-Control-Allow-Headers` fejléchez.

3. Hiba: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'."

   Ha az Access-Control-Allow-Credentials fejléc értéke true, akkor az Access-Control-Allow-Origin fejlécet egy konkrét eredetre kell beállítani, nem pedig *-ra. Ennek oka az, hogy a hitelesítő adatok minden eredetről való engedélyezése biztonsági kockázatot jelentene.

   Megoldás: Hitelesítő adatok használatakor az `Access-Control-Allow-Origin` értékét állítsa egy konkrét eredetre a `*` helyett.

4. Az előzetes kérés nem kerül elküldésre.

   Ellenőrizze duplán, hogy a Javascript kód tartalmazza-e a `credentials: 'include'` tulajdonságot. Ellenőrizze azt is, hogy a szerver engedélyezi-e az `Access-Control-Allow-Credentials: true` beállítást.

5. Ütköző konfigurációk a szerver és az ügyfél között.

   Gondosan ellenőrizze a szerveroldali CORS konfigurációt az ügyféloldali beállításokkal együtt. Az eltérések (pl. a szerver csak GET kéréseket engedélyez, de az ügyfél POST-ot küld) CORS hibákat okoznak.

CORS és biztonsági bevált gyakorlatok

Bár a CORS lehetővé teszi az ellenőrzött, eltérő eredetű hozzáférést, elengedhetetlen a biztonsági bevált gyakorlatok követése a sebezhetőségek megelőzése érdekében:

• Éles környezetben kerülje a * használatát az Access-Control-Allow-Origin fejlécben. Ez minden eredet számára hozzáférést biztosít az erőforrásaihoz, ami biztonsági kockázatot jelenthet. Ehelyett adja meg pontosan az engedélyezett eredeteket.
• Gondosan fontolja meg, mely metódusokat és fejléceket engedélyezi. Csak azokat a metódusokat és fejléceket engedélyezze, amelyek feltétlenül szükségesek az alkalmazás megfelelő működéséhez.
• Alkalmazzon megfelelő hitelesítési és jogosultságkezelési mechanizmusokat. A CORS nem helyettesíti a hitelesítést és a jogosultságkezelést. Győződjön meg róla, hogy az API-ját megfelelő biztonsági intézkedések védik.
• Ellenőrizze és tisztítsa meg az összes felhasználói bevitelt. Ez segít megelőzni a cross-site scripting (XSS) támadásokat és más sebezhetőségeket.
• Tartsa naprakészen a szerveroldali CORS konfigurációját. Rendszeresen vizsgálja felül és frissítse a CORS beállításait, hogy azok megfeleljenek az alkalmazás biztonsági követelményeinek.

CORS a különböző fejlesztői környezetekben

A CORS problémák eltérően jelentkezhetnek a különböző fejlesztői környezetekben és technológiákban. Nézzük meg, hogyan közelítsük meg a CORS-t néhány gyakori forgatókönyv esetén:

Helyi fejlesztői környezetek

A helyi fejlesztés során a CORS problémák különösen bosszantóak lehetnek. A böngészők gyakran blokkolják a helyi fejlesztői szerverről (pl. localhost:3000) egy távoli API-hoz intézett kéréseket. Számos technika enyhítheti ezt a problémát:

• Böngészőbővítmények: Az olyan bővítmények, mint az "Allow CORS: Access-Control-Allow-Origin", ideiglenesen letilthatják a CORS korlátozásokat tesztelési célokra. Azonban ezeket *soha* ne használja éles környezetben.
• Proxy szerverek: Konfiguráljon egy proxy szervert, amely továbbítja a kéréseket a helyi fejlesztői szerverről a távoli API-hoz. Ez hatékonyan "azonos eredetűvé" teszi a kéréseket a böngésző szempontjából. Az olyan eszközök, mint a http-proxy-middleware (Node.js-hez), hasznosak lehetnek ehhez.
• Szerveroldali CORS konfigurálása: Még a fejlesztés során is bevált gyakorlat, ha úgy konfigurálja az API szerverét, hogy kifejezetten engedélyezze a kéréseket a helyi fejlesztői eredetről (pl. http://localhost:3000). Ez egy valós CORS konfigurációt szimulál, és segít a problémák korai felismerésében.

Szervermentes környezetek (pl. AWS Lambda, Google Cloud Functions)

A szervermentes funkciók gyakran gondos CORS konfigurációt igényelnek. Számos szervermentes platform beépített CORS támogatást nyújt, de kulcsfontosságú, hogy helyesen konfiguráljuk azt:

• Platformspecifikus beállítások: Használja a platform beépített CORS konfigurációs opcióit. Az AWS Lambda például lehetővé teszi az engedélyezett eredetek, metódusok és fejlécek közvetlen megadását az API Gateway beállításaiban.
• Middleware/Könyvtárak: A nagyobb rugalmasság érdekében használhat middleware-eket vagy könyvtárakat a CORS kezelésére a szervermentes funkció kódján belül. Ez hasonló a hagyományos szerverkörnyezetekben alkalmazott megközelítésekhez (pl. a `cors` csomag használata Node.js Lambda funkciókban).
• Vegye figyelembe az OPTIONS metódust: Győződjön meg róla, hogy a szervermentes funkciója helyesen kezeli az OPTIONS kéréseket. Ez gyakran egy külön útvonal létrehozását jelenti, amely a megfelelő CORS fejléceket adja vissza.

Mobilalkalmazás-fejlesztés (pl. React Native, Flutter)

A CORS kevésbé közvetlen probléma a natív mobilalkalmazások (Android, iOS) esetében, mivel ezek általában nem ugyanúgy érvényesítik az azonos eredetű szabályzatot, mint a webböngészők. Azonban a CORS mégis releváns lehet, ha a mobilalkalmazás webes nézetet (web view) használ webes tartalom megjelenítésére, vagy ha olyan keretrendszereket használ, mint a React Native vagy a Flutter, amelyek JavaScriptet használnak:

• Webes nézetek (Web Views): Ha a mobilalkalmazás webes nézetet használ webes tartalom megjelenítésére, ugyanazok a CORS szabályok érvényesek, mint egy webböngészőben. Konfigurálja a szerverét, hogy engedélyezze a kéréseket a webes tartalom eredetéről.
• React Native/Flutter: Ezek a keretrendszerek JavaScriptet használnak API kérések indítására. Bár a natív környezet talán nem érvényesíti közvetlenül a CORS-t, az alapul szolgáló HTTP kliensek (pl. a fetch) bizonyos helyzetekben mégis mutathatnak CORS-szerű viselkedést.
• Natív HTTP kliensek: Amikor közvetlenül natív kódból indít API kéréseket (pl. OkHttp használatával Androidon vagy URLSessionnel iOS-en), a CORS általában nem játszik szerepet. Azonban továbbra is figyelembe kell vennie a biztonsági bevált gyakorlatokat, mint például a megfelelő hitelesítést és jogosultságkezelést.

Globális megfontolások a CORS konfigurációhoz

Amikor egy globálisan elérhető alkalmazáshoz konfigurálja a CORS-t, kulcsfontosságú figyelembe venni olyan tényezőket, mint:

• Adatszuverenitás: Egyes régiókban a szabályozások előírják, hogy az adatoknak a régión belül kell maradniuk. A CORS szerepet játszhat az erőforrások határokon átnyúló elérésekor, ami potenciálisan ütközhet az adattárolási törvényekkel.
• Regionális biztonsági irányelvek: A különböző országok eltérő kiberbiztonsági szabályozásokkal és iránymutatásokkal rendelkezhetnek, amelyek befolyásolják, hogyan kell a CORS-t implementálni és biztonságossá tenni.
• Tartalomszolgáltató hálózatok (CDN-ek): Győződjön meg róla, hogy a CDN-je megfelelően van konfigurálva a szükséges CORS fejlécek továbbítására. A helytelenül konfigurált CDN-ek eltávolíthatják a CORS fejléceket, ami váratlan hibákhoz vezethet.
• Terheléselosztók és proxyk: Ellenőrizze, hogy az infrastruktúrájában lévő terheléselosztók vagy fordított proxyk helyesen kezelik-e az előzetes kéréseket és továbbítják-e a CORS fejléceket.
• Többnyelvű támogatás: Vegye fontolóra, hogyan hat a CORS az alkalmazás nemzetköziesítési (i18n) és lokalizációs (l10n) stratégiáira. Biztosítsa, hogy a CORS irányelvek következetesek legyenek az alkalmazás különböző nyelvi verzióiban.

A CORS tesztelése és hibakeresése

A CORS hatékony tesztelése és hibakeresése létfontosságú. Íme néhány technika:

• Böngésző fejlesztői eszközök: A böngésző fejlesztői konzolja az első állomás. A "Network" fülön láthatók az előzetes kérések és a válaszok, amelyekből kiderül, hogy a CORS fejlécek jelen vannak-e és helyesen vannak-e konfigurálva.
• curl parancssori eszköz: Használja a `curl -v -X OPTIONS ` parancsot az előzetes kérések manuális küldésére és a szerver válaszfejléceinek vizsgálatára.
• Online CORS ellenőrzők: Számos online eszköz segíthet a CORS konfigurációjának validálásában. Csak keressen rá a "CORS checker" kifejezésre.
• Egység- és integrációs tesztek: Írjon automatizált teszteket annak ellenőrzésére, hogy a CORS konfigurációja az elvártaknak megfelelően működik-e. Ezeknek a teszteknek le kell fedniük mind a sikeres, eltérő eredetű kéréseket, mind azokat a forgatókönyveket, ahol a CORS-nak blokkolnia kell a hozzáférést.
• Naplózás és monitorozás: Implementáljon naplózást a CORS-szal kapcsolatos események nyomon követésére, mint például az előzetes kérések és a blokkolt kérések. Figyelje a naplókat gyanús tevékenységek vagy konfigurációs hibák szempontjából.

Következtetés

A Cross-Origin Resource Sharing (CORS) egy létfontosságú biztonsági mechanizmus, amely lehetővé teszi a webes erőforrásokhoz való ellenőrzött, eltérő eredetű hozzáférést. A CORS működésének megértése, különösen az előzetes kéréseké, kulcsfontosságú a biztonságos és megbízható webalkalmazások építéséhez. Az ebben az útmutatóban vázolt bevált gyakorlatok követésével hatékonyan kezelheti a CORS problémákat és megvédheti alkalmazását a potenciális sebezhetőségektől. Ne feledje, hogy mindig a biztonságot helyezze előtérbe, és gondosan mérlegelje a CORS konfigurációjának következményeit.

Ahogy a webfejlesztés fejlődik, a CORS továbbra is a webbiztonság kritikus aspektusa marad. A legújabb CORS bevált gyakorlatokról és technikákról való tájékozottság elengedhetetlen a biztonságos és globálisan elérhető webalkalmazások építéséhez.